Universal Serial Bus (USB) hosts such as USB host personal computers (PC hosts) are designed to enable plug-and-play operation of a number of USB peripheral devices. That is, the USB peripheral devices are automatically configured for communicating with the USB host when they are physically connected to a USB port of the USB host. USB hosts may be capable of handling up to 127 USB peripheral devices and may provide mechanisms for dynamically loading and unloading drivers for each device attached on a USB bus.
Unlike USB hosts, USB peripheral devices are generally unable to dynamically load and unload drivers for various USB functionalities. Rather, the USB peripheral devices enumerate a predefined static set of functions to the USB host when they are physically connected to the USB host. The set of static functions generally may not be extended in run-time. Certain newer USB peripheral devices may be capable of multiple USB functionalities. However, such devices may only have a limited ability to configure desired functionalities due to the inability of USB peripheral devices to dynamically load and unload USB drivers for the functionalities.
Certain composite USB devices may allow multiple USB functions to enumerate to a USB host on a single USB port. USB specifications describe certain methods for designing such composite devices by allowing the devices to enumerate with multiple functions on a single USB port.
FIG. 1 shows a USB descriptor hierarchy 100 that can represent multiple logical functions within a device in accordance with USB specifications. At least three stages of USB enumeration may occur when a USB device is plugged in to a host. A device descriptor 102 represents a USB enumeration for a device. A number of configuration descriptors 104 represent USB enumeration for various configurations of the device. A number of interface descriptors 106 may each represent a USB enumeration for a corresponding one of the USB functionalities. A number of endpoint descriptors 108 enumerate assignments for data channels to a particular interface. The endpoint descriptors 108 allow a particular functionality to access specific data channels in order to transfer data back and forth to the USB host, for example.
Because the descriptor hierarchy 100 shown in FIG. 1 is static, additional interfaces generally may not be added to the hierarchy unless a physical disconnection and reconnection of the device occurs or is simulated. Certain USB devices allow reconfiguration of a descriptor hierarchy 100 by internally opening and closing USB circuitry connecting the USB device to the USB host to simulate disconnection and reconnection of the USB device from/to the USB host. However, this method is often susceptible to errors due to disconnection and reconnection of all logical interfaces, which can tear down active application sessions in an unexpected manner.
Opening and closing USB circuitry to allow re-enumeration of USB functionality may also be problematic, for example, in the process of charging a dead battery of a USB peripheral device. According to the USB specification, a USB peripheral device may draw up to 100 mA from a USB host before the USB peripheral device enumerates and may request up to 500 mA from the USB host after the USB peripheral device enumerates. However, a USB peripheral device may have to draw more than 100 mA to load its operating system. To recover from a discharged battery, a USB device may enumerate to a USB host early in a boot loading process. The initial enumeration may occur before loading the USB peripheral operating system and may use only up to 100 mA of current.
To further conserve power during a boot process with a discharged battery, a USB peripheral device may initially enumerate as a simpler USB peripheral device, such as a USB human interface device (HID) Class device, for example. After the initial enumeration of the USB peripheral device is complete, the USB peripheral device may request up to 500 mA from the USB host. The additional current may be used to finish loading the USB peripheral's operating system. Once the operating system is loaded, the USB peripheral device will generally re-enumerate to represent its actual functionalities to the USB host as specified by the operating system.
A re-enumeration may be performed by opening and closing USB circuitry to simulate a reconnection of the USB device as described above. However, the USB specification would then mandate reducing the charging current from around 500 mA to a pre-enumeration level of less than 100 mA. Therefore, opening and closing the USB circuitry to re-enumerate the USB device functionally can not be performed in a USB compliant manner until the battery is sufficiently charged.
Simulating disconnection/reconnection of a USB peripheral device may also cause other undesirable side effects. For example, the naming of hardware ports in certain operating systems may be automatically updated when the operating system recognizes a physical disconnection/reconnection of a USB device. This may cause errors in processes that are accessing renamed ports.
USB specifications define a method of packaging multiple USB devices within a single compound device package with an embedded USB hub. An example of a compound device including an embedded USB hub is described with reference to FIG. 2. A root hub 202 may be connected directly to a USB host 204 and a number of USB devices 206 may be connected to the USB host 204 via the root hub 202. A number of additional devices 208 may be connected to the root hub 202 via a number of additional USB hubs 210. Certain compound devices may include a USB hub 210 having one or more connected USB devices 208.
Connecting a USB device to a USB host via one or more USB hubs may solve some of the problems associated with recharging a USB device described above. Because the USB hub is a comparatively simple device, it may enumerate during an initial boot loading process without a re-enumeration step. After its initial enumeration, the USB hub can increase its current draw from the USB host from less than 100 mA to about 500 mA and may keep drawing 500 mA until the battery is charged. The current draw of up to 500 mA may be maintained even as devices are added and removed from the configuration via the USB hub.
Even though devices such as USB hubs may enumerate multiple functions on a single USB port, such functions are statically defined and may not be changed in run-time. Moreover, USB host operating systems may have multiple specifications or limitations that may restrict the USB host's interactions with such composite USB devices. Proprietary drivers may be developed for composite devices with these operating system limitations in which dedicated product identifies (IDs) may be assigned for each possible combination of logical functions, for example.
Efforts to provide dynamically configurable USB functionality on USB peripheral devices have included implementing composite drivers in the primary processor of the USB peripheral device. However, such composite drivers have been inherently limited because they manage all combinations of possible USB functionalities and assign a separated product ID for each combination. Some implementations define a product ID for a super set of functions known at the time of system design and enumerate with a subset of the functions based on the specific scenario. In either case, adding a new USB functionality is complex and involves re-enumeration of all functions.
Dedicated USB hub chips have been added to USB peripheral devices for compound device implementation. Compound USB hub devices that have one or more downstream ports exposed in addition to certain embedded USB functions are also available in the market. One example of such a compound device is shown in FIG. 3. The device 300 shown in FIG. 3 is an example of a USB compound hub with SD card slots 302 and an embedded card reader function. USB compound devices can handle multiple independent functions hosted on different processors. However, USB compound devices involve extra cost and extra power consumption on independent physical USB interfaces to each processor. In addition, each processor attached to the embedded USB hub chip still has the same limitations as those of a stand alone USB device.
On certain multi-processor systems with a single USB port, such as a micro-B port or a micro-AB port, for example, each processor may expose certain USB functionality to the USB bus. The multiple USB functionalities have been exposed by hosting the corresponding USB drivers on a single primary processor. This may be inefficient because, for example, other processors in the multi-processor systems, i.e., secondary processors, may be subject to an increased burden of additional processing to communicate with USB hardware via a primary processor.